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A Registry for SMTP Enhanced Mail System Status Codes 
Status of This Memo 


This document specifies an Internet Best Current Practices for the 
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited. 


Abstract 


The specification for enhanced mail system status codes, RFC 3463, 
establishes a new code model and lists a collection of status codes. 
While it anticipated that more codes would be added over time, it did 
not provide an explicit mechanism for registering and tracking those 
codes. This document specifies an IANA registry for mail system 
enhanced status codes, and initializes that registry with the codes 
so far established in published standards-track documents, as well as 
other codes that have become established in the industry. 
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1. Introduction 


Enhanced Status Codes for SMTP were first defined in [RFC1893], which 
was subsequently replaced by [RFC3463]. While it anticipated that 
more codes would be added over time (see section 2 of [RFC3463]), it 
did not provide an explicit mechanism for registering and tracking 
those codes. Since then, various RFCs have been published and 
internet drafts proposed that define additional status codes. 
However, without an IANA registry, conflicts in definitions have 
begun to appear. 


This RFC defines such an IANA registry and was written to help 
prevent further conflicts from appearing in the future. It 
initializes the registry with the established standards-track 
enhanced status codes from [RFC3463], [RFC3886], [RFC4468], and 
[RFC4954]. In addition, this document adds several codes to the 
registry that were established by various internet drafts and have 
come into common use, despite the expiration of the documents 
themselves. 


As specified in [RFC3463], an enhanced status code consists of a 
three-part code, with each part being numeric and separated by a 
period character. The three portions are known as the class sub- 
code, the subject sub-code, and the detail sub-code. In the tables, 
a wildcard for the class sub-code is represented by an X, a wildcard 
for a subject sub-code is represented by an XXX, and a wildcard for a 
detail sub-code is represented by a YYY. For example, 3.XXX.YYY has 
an unspecified subject sub-code and an unspecified status code, and 
X.5.0 is has an unspecified class sub-code. (This is a change from 
[RFC3463], which uses XXX for both the subject sub-code and detail 
sub-code wildcards.) 


2. IANA Considerations 
2.1. SMTP Enhanced Status Codes Registry 


IANA has created the registry "SMTP Enhanced Status Codes". The SMTP 
Enhanced Status Codes registry will have three tables: 


o Class Sub-Codes 
Each of the entries in this table represent class sub-codes and 
all have an unspecified subject sub-code and an unspecified detail 
sub-code. 


o Subject Sub-Codes 
Each of the entries in this table represent subject sub-codes and 
all have an unspecified class sub-code and an unspecified detail 
sub-code. 
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o Enumerated Status Codes 


Each of the entries in this table represent the combination of a 
subject sub-code and a detail sub-code. All entries will have an 


unspecified class sub-code, 
specified detail sub-code. 


a specified subject sub-code, anda 


Each entry in the tables will include the following. (The sub-code 
tables will not have the Associated Basic Status Code entries.) 


Code: 


Summary: or Sample Text: 


Associated Basic Status Code: 


Description: 


Reference: 


The status code. For example, 
3.XXX.YYY is a class sub-code with an 
unspecified subject sub-code and an 
unspecified detail sub-code, and X.5.0 
is an enumerated status code with an 
unspecified class sub-code. 


For class and subject sub-codes, this 
is the summary of the use for the sub- 
code shown in section 2 of [RFC3463]. 
For enumerated status codes, this is an 
example of a message that might be sent 
along with the code. 


For enumerated status codes, the basic 
status code(s) of [RFC2821] with which 
it is usually associated. This may 
also have a value such as "Any" or "Not 
given". NOTE: This is a non-exclusive 
list. In particular, the entries that 
list some basic status codes for an 
Enhanced Status Code might allow for 
other basic status codes, while the 
entries denoted "Not given" can be 
filled in by updating the IANA registry 
through updates to this document or at 
the direction of the IESG. 


A short description of the code. 


A reference to the document in which 
the code is defined. This reference 
should note whether the relevant 
specification is standards-track, best 
current practice, or neither, using one 
of "(Standards track)", "(Best current 
practice)" or "(Not standards track)". 
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Submitter: The identity of the submitter, usually 
the document author. 


Change Controller: The identity of the change controller 
for the specification. This will be 
"IESG" in the case of IETF-produced 
documents. 


An example of an entry in the enumerated status code table would be: 


Code: X.0.0 

Sample Text: Other undefined Status 

Associated basic status code: Any 

Description: Other undefined status is the only undefined 
error code. It should be used for all errors for 
which only the class of the error is known. 

Reference: RFC 3463 (Standards track) 

Submitter: G. Vaudreuil 


Change controller: IESG. 
2.2. Review Process for New Values 


Entries in this registry are expected to follow the "Specification 
Required" model ([RFC5226]) although, in practice, most entries are 
expected to derive from standards-track documents. Non-standards-— 
track documents that specify codes to be registered should be readily 
available. The principal purpose of this registry is to avoid 
confusion and conflicts among different definitions or uses for the 
same code. 


2.3. Registration Updates 


Standards-track registrations may be updated if the relevant 
standards are updated as a consequence of that action. Non- 
standards-track entries may be updated by the listed change 
controller. Only the entry’s short description or references may be 
modified in this way, not the code or associated text. In 
exceptional cases, any aspect of any registered entity may be updated 
at the direction of the IESG (for example, to correct a conflict). 
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2.4. Initial Values 


The initial values for the class and subject sub-code tables are to 
be populated from section 2 of [RFC3463]. Specifically, these are 
the values for 2.XXX.YYY, 4.XXX.YYY, and 5.XXX.YYY for the Class Sub- 
Code table, and the values X.0.YYY, X.1.YYY, X.2.YYY, X.3.YYY, 
X.4.YYY, X.5.YYY, X.6.YYY, and X.7.YYY for the Subject Sub-Code 
table. The code, sample text, and description for each entry are to 
be taken from [RFC3463]. Each entry is to use [RFC3463] as the 
reference, submitted by G. Vaudreuil, and change controlled by the 
IESG. There are no associated detail sub-code values for the class 
and subject sub-code tables. 


The initial values for the Enumerated Status Code table is to be 
populated from: 


1. sections 3.1 through 3.8 of [RFC3463], (X.0.0, X.1.0 through 
X.1.8, X.2.0 through X.2.4, X.3.0 through X.3.5, X.4.0 through 
X.4.7, X.5.0 through X.5.5, X.6.0 through X.6.5, and X.7.0 


through X.7.7), 
2. section 3.3.4 of [RFC3886] (X.1.9), 


3. X.6.6 found in section 5 of [RFC4468], (but not X.7.8 found in 
the same section), 


4. and X.5.6, X.7.8, X.7.9, X.7.11, and X.7.12, found in section 6 
of [RFC4954] (using the text from X.5.6, 5.7.8, 5.7.9, 5.7.11, 
and 4.7.12). 


Each entry is to be designated as defined in the corresponding RFC, 
submitted by the corresponding RFC author, and change controlled by 
the IESG. Each of the above RFCs is a standards-track document. 


The initial values for the Associated Basic Status Code for each of 
the above initial enhanced status codes is given in the following 
table. 


As noted above, this table is incomplete. In particular, the entries 
that have some basic status codes might allow for other detail sub- 
status codes, while the entries denoted "Not given" can be filled in 
by updating the IANA registry through updates to this document or at 
the direction of the IESG. 
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+-------- +------------- 
| Enh. | Assoc. 
Status Status Code 
Code 
| | 
+-------- +------------- 
| X.0.0 | Any 
| | 
Kaka? Not given 
X.1.5 250 
| | 
| x.1.8 | 451, 501 
| | 
| Xe | Not given 
| So2.4 || 450; 452 
| | 
| | 
| 1322 ~ || 458 
| | 
| XAO | Not given 
| X.4.2 | 421 
| x.4.5 | 451 
| | 
| X50 | 220; 250; 
251; 252, 
253, 451, 
| | 452, 454, 
| | 458, 459, 
| | -5017 502; 
| | 503, 554 
| X.5.3 | 451 
| | 
| | 
| | 
| | 
| X.5.6 | 500 
| X.6.2 | Not given 
| X.6.5 | Not given 
| | 
| | 
| | 
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| x.7.1 | 451, 454, | x.7.2 | 550 | X.7.3 | Not given 

| | 502, 503, | | | | | 
533, 550, 551 

| X.7.4 | 504 | X.7.5 | Not | X.7.6 | Not given 

| | | | given | | | 

| X.7.7 | Not given | x.7.8 | 535, 554 | X.7.9 | 534 

| xX.7.10 | 523 |) Mee Peed | 524; 588] KS STOL | 4927 432 

| xX.7.13 | 525 Ser Telas | 5357554] | 

+-------- +--------------- +-------- +---------—- +-------- +------------- + 

Table 1 


The following additional definitions have been registered in the 
enumerated status code table. These entries have been used in the 
industry without any published specification. 


Code: X73 8) 

Sample Text: Encryption Needed 

Associated basic status code: 523 

Description: This indicates that an external strong privacy 
layer is needed in order to use the requested 
authentication mechanism. This is primarily 


intended for use with clear text authentication 
mechanisms. A client that receives this may 
activate a security layer such as TLS prior to 
authenticating, or attempt to use a stronger 


mechanism. 
Reference: RFC 5248 (Best current practice) 
Submitter: T. Hansen, J. Klensin 


Change controller: IESG 


Hansen & Klensin Best Current Practice [Page 7] 


RFC 5248 SMTP Enhanced Status Code Registry June 2008 


Code: Male ls8 

Sample Text: User Account Disabled 

Associated basic status code: 525 

Description: Sometimes a system administrator will have to 


disable a user’s account (e.g., due to lack of 
payment, abuse, evidence of a break-in attempt, 
etc.). This error code occurs after a successful 
authentication to a disabled account. This 
informs the client that the failure is permanent 
until the user contacts their system 
administrator to get the account re-enabled. It 
differs from a generic authentication failure 
where the client’s best option is to present the 
passphrase entry dialog in case the user simply 
mistyped their passphrase. 

Reference: RFC 5248 (Best current practice) 

Submitter: T. Hansen, J. Klensin 

Change controller: IESG 


Code: X.7.14 

Sample Text: Trust relationship required 

Associated basic status code: 535, 554 

Description: The submission server requires a configured trust 
relationship with a third-party server in order 
to access the message content. This value 


replaces the prior use of X.7.8 for this error 
condition, thereby updating [RFC4468]. 
Reference: RFC 5248 (Best current practice) 
Submitter: T. Hansen, J. Klensin 
Change controller: IESG 


3. Security Considerations 


As stated in [RFC1893], use of enhanced status codes may disclose 
additional information about how an internal mail system is 
implemented beyond that available through the SMTP status codes. 


Many proposed additions to the response code list are security 
related. Having these registered in one place to prevent collisions 
will improve their value. Security error responses can leak 
information to active attackers (e.g., the distinction between "user 
not found" and "bad password" during authentication). Documents 
defining security error codes should make it clear when this is the 
case so SMTP server software subject to such threats can provide 
appropriate controls to restrict exposure. 
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